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PRE-APPEAL BRIEF REQUEST FOR REVIEW AND STATEMENT OF REASONS 

Sir: 

Applicants request review of the Final Rejection dated March 25, 2010. No amendments are 
being filed with the request. This request is being filed with a Notice of Appeal. The following sets 
forth a succinct, concise, and focused set of arguments for which the review is being requested. 



Claims 2-6 were finally rejected as obvious over U.S. Patent Publication No. 2003/0172177 
to Kersley et al. in view of U.S. Patent Publication No. 2002/0190356 to Buechler et al. as 
evidenced by English, ADA 95: The Craft of Object-Oriented Programming. Applicants filed an 
Amendment After Final proposing amendments to clarify that "a single flag" is used for each packet 
class, but these amendments were not entered in the Advisory Action dated June 16, 2010. 
Applicants respectfiiUy traverse the rejections for the reasons set forth below. 

Applicants have invented a device verification method which provides a single dual-state 
flag for each of a plurality of packet classes . As recited, the single flag can have either a first state 
(e.g., "0" to indicate that the packet class has not been tested) or a second state (e.g., "1" to indicate 
that the packet class has been tested). It bears emphasis that the claims singularly and consistently 
recite "the flag" with reference to the earlier recitation of "a flag" which provides the antecedent 
basis for the recited single flag. When a packet from a packet class is generated, the single flag for 
that packet class is checked to see if it is in a first state, and if so, that packet is used to test the 
device for that packet class and the flag is changed to the second state. See, e.g., claim 2. On the 
other hand, if the single flag for that packet class is in a second state, the packet is not used to test 
the device for that packet class. See, e.g., claim 3. In this way, a device is tested by packet class 
since a packet within each packet class will only be used to test the device if the flag for that 
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packet class has not been set to the second state. With Applicants' invention, packets need not be 
stored in memory, but can instead be "generated" as claimed (e.g., randomly), and each generated 
packet in a given packet class can be checked against the flag for that packet class to determine if 
the packet will be used to test the device. This approach eliminates the costs associated with storing 
all possible packets to be tested, and also eliminates the inefficient testing of devices with redundant 
packets by using a single flag for each packet class to determine if a generated packet in the packet 
class will be used to test the device. 

In rejecting claims 2-6 as obvious over Kersley, Buechler and English, the Examiner asserts 
that Kersley's disclosed method for verification of a device-under-test (Kersley, Fig. 2, ^ 5-7, 18, 
21-22, 35, and 43) meets the claim requirements except for variously recited requirements of (1) 
"providing a flag, which may be of a first or a second state, for each of the plurality of packet 
classes" (claims 2-6); (2) testing the device "if the flag of the packet class of the generated packet is 
in the first state" (claims 2-3 and 5-6); (3) not testing the device "if the flag of the packet class of 
the generated packet is in the second state" (claims 3-6); and (4) "changing the flag of the packet 
class of the generated packet to the second state" if the flag of the packet class of the generated 
packet is in the first state (claims 2 and 5-6). See, Office Action , pp. 2-6. To overcome these 
deficiencies in Kersley's disclosure, the Examiner cites Buechler's disclosure (Buechler, T| 78) of 
using "record flags" to assure that all required assay tests are performed and to avoid duplication of 
testing. Id., pp. 6-8. In the rejection analysis, the Examiner does not recognize that a single flag is 
used for each packet class to convey the test status of the packet class, asserting that "the claims 
does (sic, do) not explicitly state 'a single flag', but merely 'a flag'. This claimed language does 
not exclude the possibility of having multiple flags for a packet class, but merely states that there is 
a flag for a packet class." See, Office Action , pp. 8-9 (emphasis in original). As a result, the 
Examiner asserts that Buechler's two separate flags meet the claim limitation of "a flag." Id. 

In reply. Applicants respectfully submit that the Examiner's proposed interpretation and 
application of the claims is incorrect because it fails to take into account the clear and explicit claim 
requirements that there is "a flag" with two states, that the device is tested with a packet if "the 
flag" is in a first state, and that "the flag" is changed to the second state if "the flag" is in the first 
state. The singular nature of "tiie flag" recited in the claims follows directly from the claim 
formatting requirements for reciting an antecedent basis for the claimed "flag" limitation, and 
Applicants submit that persons having ordinary skill in the art would readily understand as much 
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from the recited language. Applicants proposed reading of the claims is consistent, not only with 

the explicit requirements of "the flag" in claims, but also with the intrinsic evidence: 

In the present method for use in verification of a device, a plurality of injection flags are 
provided, with one each of which is associated of a plurality of packet classes . Each 
injection flag may be of a first or a second state. Next, a packet is generated. If the injection 
flag of the packet class of the generated packet is in the second state, it is indicated that a 
packet of that packet class has already been generated, and the device is not tested. If the 
injection flag of the packet class of the generated packet is in the first state, the device is 
tested and the injection flag of the packet class of the generated packet is set to the second 
state. 

* * * 

Figure 1 illustrates the steps of the present invention. In the present simulation, initially, 
each legal packet class is provided with a 1-bit injection flag . 

See, Application, p. 2, lines 1-9 and 32-33. As these passages show. Applicants have disclosed and 

claimed using a single flag for each packet class to drive and determine these various actions (test, 

not test, change flag state). In contrast, the cited art explicitly discloses using a plurality of record 

flags to track tests and prevent duplication. See, Bucchlcr, *![ 78 ("In order to assure that all required 

tests are performed, and also to avoid duplication of testing, record flags or other techniques can be 

used when the database 464 is accessed to retrieve test instructions. For example, when fluorometer 

100 accesses information system 408 to receive instructions for a particular test, that test is flagged 

as being performed such that subsequent accesses by this or another fluorometer 100 will not 

retrieve the same test instructions. Once a test is completed and the results provided to information 

system 408, another flag can be set indicating the status of the test as being completed.") (emphasis 

added). Thus, Applicants' approach is more efficient than the cited art because Applicants use a 

single flag to convey test status information for each packet, while the cite art uses multiple record 

flags to track tests and prevent duplicate testing. 

In this case, the rejection analysis appears to have mischaracterized the claimed invention by 

ignoring the requirement that a single flag be used for each packet class to determine: 

(1) whether the device is tested with the generated packet (as variously required in claims 2- 
3 and 5-6 which require device testing "if the flag of the packet class of the generated packet 

is in the first state"); 

(2) whether the device is not tested with the generated packet (as variously required in 
claims 3-6 which require no device testing "if the flag of the packet class of the generated 
packet is in the second state"); and/or 

(3) whether the flag is changed to a second state (as variously required in claims 2 and 5-6 
which require changing the flag state if the flag of the packet class of the generated packet is 
in the first state"). 
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See, e.g., claims 2-5. In short, Applicants have disclosed and claimed using a single flag for each 
packet class to drive and determine these various actions (test, not test, change flag state). 

Against this backdrop. Applicants urge reconsideration and withdrawal of the rejection over 
Kersley, Buechler and English because the proposed combination fails to disclose or address the 
variously recited requirements in claims 2-3 and 5-6 of testing the device "if the flag of the packet 
class of the generated packet is in the first state" since Buechler discloses accessing the test 
instructions without first checking the state of an associated flag for the test. Likewise, rather than 
meeting the variously recited requirements in claims 3-6 of not testing the device "if the flag of the 
packet class of the generated packet is in the second state," Buechler discloses accessing "another 
flag" (not the same flag) to see if the test has been completed. Finally, rather than meeting the 
variously recited requirements in claims 2 and 5-6 of changing the flag to the second state "if the 
flag of the packet class of the generated packet is in the first state," Buechler discloses setting 
"another flag can be set" (not the same flag) "[o]nce a test is completed and the results provided to 
information system 408." In sum, Buechler uses two flags, not one flag as claimed, and sets the 
flags in response to different triggers than claimed. Buechler' s use of multiple flags for each test 
should come as no surprise since Buechler's fluorometer testing scheme is concerned with only a 
limited number of tests, so there would be no significant penalty in tracking multiple flags for each 
test. In contrast, Apphcants' disclosed verification scheme is being used to test devices with 
"several thousand different combinations" of possible packet classes being tested. See, Application , 
p. 1, lines 20-21. 

Another problem with the cited art is that neither Kersley nor Buechler disclose or suggest 
"providing a plurality of packet classes ." much less "providing a flag ... for each of the plurality of 
packet classes " as recited in each of the pending claims. On this point. Applicants have carefully 
review the cited disclosure from Kersley (Fig. 2, ^ 5-7, 18, 21-22, 35, 43), but there is absolutely 
no teaching or suggestion of any "packet class," much less of providing a single flag for each 
"packet class." And while Buechler discloses maintaining a flag for each assay test performed by 
the fluorometer, there is no suggestion of maintaining a flag for a class of tests. Thus, there is 
simply no teaching or suggestion that the cited art combination provides "a plurality of packet 
classes" with a (single) flag "for each of the plurality of packet classes," as recited in the claims. 
Instead of being concerned with testing by packet class, Kersley is concemed with verifying a 
device-under-test by "generating packets to simulate complex network packet traffic patterns to test 
and verify a device under test (DUT)." Kersley, paragraph 5. 
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Based on the foregoing and putting aside for the moment the propriety of combining the 
Kersley, Buechler and English references, Applicants submit that a prima facie case of obviousness 
has not been established for claims 2-6 because the Examiner has not met the burden of showing 
that all the claim limitations are taught or suggested by the prior art. In the absence of any 
disclosure by the cited art references of a device verification method which provides a single flag 
for each of a plurality of packet classes for purposes of performing device verification testing on 
each packet, the Examiner has not made the prima facie showing that each and every element of the 
claimed invention, arranged as required by the claims, is found in the cited art. When determining 
whether a claim is obvious, an Examiner must make "a searching comparison of the claimed 
invention - including all its limitations - with the teaching of the prior art." In re Ochiai . 71 F.3d 
1565, 1572 (Fed. Cir. 1995) (emphasis added). Thus, "obviousness requires a suggestion of all 
limitations in a claim." CFMT. Inc. v. Yieldup Intem. Corp. . 349 F.3d 1333, 1342 (Fed. Cir. 2003) 
(citine In re Rovka . 490 F.2d 981, 985 (CCPA 1974)). Moreover, the Supreme Court has made 
clear that ""there must be some articulated reasoning with some rational underpinning to support the 
legal conclusion of obviousness." KSR Int'l v. Teleflex Inc. . 127 S.Ct. 1727, 1741 (2007) {quoting 
In re Kahn . 441 F.3d 977, 988 (Fed. Cir. 2006) (emphasis added)). Accordingly, Applicants 
respectfully request that the obviousness rejection of claims 2-6 be reconsidered and withdrawn, 
and that the claims be allowed. 

CONCLUSION 

In view of the remarks set forth herein, the application is believed to be in condition for 
allowance and a notice to that effect is solicited. Nonetheless, should any issues remain that might 
be subject to resolution through a telephone interview, the Examiner is requested to telephone the 
undersigned at 512-338-9100. 



CERTIFICATE OF TRANSMISSION 

I hereby certify that on June 22, 2010, this correspondence is 
being transmitted via the U.S. Patent & Trademark Office's 
electronic filing system. 

/Michael Rocco Cannatti/ 



Respectfully submitted, 

/Michael Rocco Cannatti/ 

Michael Rocco Cannatti 
Attorney for Applicants 
Reg. No. 34,791 



5 



